The destination rectangle in the texture array may not include any texels
outside the texture array as it was originally specified. It is not an
error to specify a subtexture with zero width or height, but such a
specification has no effect.
If any of the pixels within the specified rectangle of the current
GGGGLLLL____RRRREEEEAAAADDDD____BBBBUUUUFFFFFFFFEEEERRRR are outside the read window associated with the current
rendering context, then the values obtained for those pixels are
undefined.
When GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____RRRREEEEAAAADDDD____IIIINNNNGGGGRRRR is enabled, every other row of the source
pixel rectangle is read. The height of the source pixel rectangle is
equivalent to 2xheight. Only rows (y+0,y+2,...) of the source are used
to define the rows of the texture subimage that are affected by the copy.
When GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled, source pixels are written to every
other row in the texture subimage, rather than to every successive row.
The height of the subimage is equivalent to 2xheight. Rows
(yoffset+0,yoffset+2,...) of the destination texture are affected, while
rows (yoffset+1,yoffset+3,...) are not modified. A complete video frame
may be assembled in texture memory by invoking ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT on
two consecutive video fields, with _y_o_f_f_s_e_t values that differ by one.
NNNNOOOOTTTTEEEESSSS
ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT is part of the EEEEXXXXTTTT____ccccooooppppyyyy____tttteeeexxxxttttuuuurrrreeee extension,
GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is part of the SSSSGGGGIIIIXXXX____iiiinnnntttteeeerrrrllllaaaacccceeee extension, and
GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____RRRREEEEAAAADDDD____IIIINNNNGGGGRRRR is part of the IIIINNNNGGGGRRRR____iiiinnnntttteeeerrrrllllaaaacccceeee____rrrreeeeaaaadddd extension. See
ggggllllIIIInnnnttttrrrroooo for more information about using extensions.
EEEERRRRRRRROOOORRRRSSSS
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM is generated when _t_a_r_g_e_t is not one of the allowable
values.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _l_e_v_e_l is less than zero or greater than
log (_m_a_x), where _m_a_x is the returned value of GGGGLLLL____MMMMAAAAXXXX____TTTTEEEEXXXXTTTTUUUURRRREEEE____SSSSIIIIZZZZEEEE.
2
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if xoffset<-TEXTURE_BORDER,
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT is executed
between the execution of ggggllllBBBBeeeeggggiiiinnnn and the corresponding execution of
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems do not support color
matrix transformations on images as they are loaded to or read back from
texture memory.
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems support
ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDD and ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT with the following
restrictions:
1. Only level 0 is supported; other levels result in a
2. The texel offsets and the dimensions of the subimage must be
multiples of 32; otherwise a GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE error is
generated.
3. If ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDD or ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT is used when a
GLX video source is the read drawable (see
ggggllllXXXXMMMMaaaakkkkeeeeCCCCuuuurrrrrrrreeeennnnttttRRRReeeeaaaaddddSSSSGGGGIIII), the X offset and Y offset must both be 0
and the subimage width must be 768; otherwise a GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE
error is generated.
4. GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is not supported (see ggggllllEEEEnnnnaaaabbbblllleeee).
On IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy systems, there is a performance benefit when the width
of the image to be transferred to texture memory is a multiple of 8.
Texture borders are not supported on IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy systems.
Applications should use borderless textures and GGGGLLLL____CCCCLLLLAAAAMMMMPPPP____TTTTOOOO____EEEEDDDDGGGGEEEE____SSSSGGGGIIIISSSS
wrap mode.
On HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt systems, if the right side of the image
to be transferred to texture memory is not the right side of the texture,
then its index must be a multiple of 32, where index = xoffset+width.
Otherwise it will generate a GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE error.
The SSSSGGGGIIIIXXXX____iiiinnnntttteeeerrrrllllaaaacccceeee extension is supported only on IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy
systems, on RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems, on OOOOccccttttaaaannnneeee2222
VVVVPPPPrrrroooo systems, and on OOOO2222 systems.
The IIIINNNNGGGGRRRR____iiiinnnntttteeeerrrrllllaaaacccceeee____rrrreeeeaaaadddd extension is supported only on OOOOccccttttaaaannnneeee2222 VVVVPPPPrrrroooo
On OOOO2222 systems, when the current _r_e_a_d drawable is a DM pbuffer, using
ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDD or ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT to copy into a full texture
image whose dimensions and format match those of the pbuffer causes a
copy-by-reference. This has performance advantages, especially for
video-generated DMbuffers, because it provides a DMA path for updating
textures. Following the copy, rendering to the pbuffer or otherwise
modifying the DMbuffer, will directly affect texture memory. However,
this behavior is essentially an unspecified side-effect of the
implementation on OOOO2222, and cannot be used on other systems.